1. Field of the Invention
The embodiments of the invention generally relate to securing eCommerce and similar transactional relationships, including the sales of goods and services, between parties over computer networks such as the Internet and to tracking of distributed electronic items, such as electronic documents, electronic presentations, electronic works and to methods and systems for storing encrypted individual agreement identifiers within the distributed electronic items.
I. Background and Summary of Original Disclosure Application Ser. No. 10/970,051 and U.S. Pat. No. 6,839,692 Priority Date: Dec. 1, 2000
The present invention generally relates to a system for providing security for purchase transactions made over a network and more particularly to an improved security system that only stores and provides encrypted information. Additionally, the invention relates to a system for providing customer controlled rules, including time and value limits, for purchase transactions made over a network.
The increase in popularity of personal computers and of networks connecting personal computers has caused a dramatic increase in electronic commerce (e-Commerce) in recent decades. One example of a very popular network is the World Wide Web (WWW) or Internet. However, one aspect that has been hampering e-commerce is the inability to provide a convenient and secure payment system.
Many conventional e-commerce payment systems require elaborate passwords/encoding algorithms that are cumbersome and not user-friendly. Other conventional e-commerce payment systems require all parties involved to agree on a security format. Such systems suffer from the disadvantage that only those parties that have joined the “club” and have agreed to the specific encoding format can participate. Considering the rate at which merchant sites are being added and withdrawn from current networks (e.g., Internet), requiring merchants to agree on a specific format is unrealistic.
Other e-commerce payment systems require prepayments to a third-party vendor that, in turn, issues a coded credit against that deposit. Besides creating yet another layer to online transactions, these “wallet” and “Internet cash” programs also create another layer of exposure for the customer's information. Additionally, these systems require that both the customer and merchant register to participate in the various versions of these systems.
Still other e-commerce payment systems require the user to purchase specific hardware (e.g., a credit card reader) that is proprietary in nature and awkward to install and use. In addition, the user is required to transport the hardware device if purchases are to be made at other computers, which hampers this type of payment system.
No matter the payment system, the common thread shared by conventional systems is that the customer must provide private information in order to complete a transaction—to the merchant, to a potential third-party, and to the merchant's financial institution. This requirement is the biggest impediment to conventional systems because of the exposure to the customer, perceived or otherwise. Whether the customer obtains additional hardware or merely entrusts private information to third-party vendors, the customer's information ends up stored in someone else's database. The vulnerability of these stored records is a matter of deep concern to potential customers and to policy makers.
The problem is a matter of how many times a customer must expose private, sensitive, and/or confidential information in order to transact business over a network environment such as the Internet.
It is, therefore, an object of the present invention to provide a structure and method of securing purchase transactions over a computer network. The invention encrypts customer information as a customer code on a storage device on a customer computer (the customer computer is connected to the computer network). Then the invention supplies the customer code to a merchant in a purchase transaction over the computer network and forwards, or allows the merchant to forward, the customer code to a financial institution over the computer network. The financial institution decrypts the customer code, verifies the information, and returns a purchase authorization decision to the merchant over the computer network.
An important feature of the invention is that encoded customer information, such as credit card numbers (“customer code”), is not available to merchants and, therefore, is not vulnerable to the merchant's security or privacy entrustments. The customer code is stored on the customer's storage device only, and it is in encrypted form. This allows the customer to complete merchant transactions without revealing certain of the encrypted information to the merchant, such as credit card numbers. The financial institution compares, inter alia, the customer address with historic address information of the customer maintained by the financial institution. Customers may maintain more than one authorized shipping address. The purchase authorization decision is approved only if the customer address and the historic address are consistent. If authorization is not approved, on the basis of incorrect address information, the options to the financial institution include: 1) approving the transaction with the corrected address; 2) approving the transaction subject to the customer updating his/her address information prior to the issuance of the authorization code; and, 3) declining authorization.
Securing the customer's information before it is exposed to a network environment allows the customer to retain control and expand the use of his/her credit facility online. This is a paramount difference between the present invention and conventional e-commerce payment systems.
The present invention allows the customer to access his/her information by means of a personal key, or access code, however only the financial institution and its agents possess the decryption key, or code. Thus, the invention provides secure use of the customer's information without adding layers or third-parties and without exposing that information to a myriad of databases. In the preferred embodiment, the customer code includes encrypted credit card information.
In an additional embodiment, the invention can encrypt many customer codes on the storage device. Each of the customer codes can include a unique payment method. Alternatively, one group of the customer codes can identify a single credit organization for payment, wherein each customer code in the group includes a different user name. This allows each customer code in the group to include unique credit limits and allows the customer to authorize additional users for a single credit organization or facility. The invention also uses a password on the customer computer to unlock the customer code.
In another embodiment, the invention comprises a system that operates on a customer computer. The inventive system includes an encrypter adapted to encrypt customer information as a customer code on a storage device on the customer computer and a populator adapted to supply the customer code to a merchant in a purchase transaction over the computer network. The customer computer includes a network connection adapted to forward the customer code to a financial institution over the computer network. The financial institution decrypts the customer code and returns a purchase authorization decision to the merchant over the computer network.
The customer code preferably includes encrypted customer address information, and the system further comprises a comparator located at the financial institution. The comparator compares the customer address with a historic address of the customer maintained by the financial institution. The purchase authorization decision is approved only if the customer address and the historic address are consistent.
The system can optionally include an intermediate code confirmation site, external to the customer computer, and connected to the computer network. The intermediate code confirmation site receives the customer code prior to forwarding the customer code to the financial institution over the computer network. The intermediate confirmation site confirms whether the customer code has a proper encryption format.
The encrypter can also encrypt a plurality of customer codes on the storage device. As mentioned above, each of the customer codes can include a unique payment system or a group of the customer codes can identify a single credit organization for payment. Each customer code in the group can have a different user name and unique credit limits. The inventive system also includes a graphic user interface that can receive a password on the customer computer to unlock the customer code.
II. Background and Summary of Continuation-In-Part application Ser. No. 11/844,408 Claiming Priority to U.S. Provisional Application 60/890,230 Priority Date: Feb. 16, 2007
The Internet has changed the way people communicate and the way they do business. With that change, the way of doing things on the Internet has also evolved. As computers and technology opened a new era, software was packaged on disks and sold. Downloadable or otherwise transferable media, such as digital music and movies, soon followed. This activity led certain individuals and groups to seek ways to profit from the unauthorized copying and sale of these products, which became two basic businesses—one that sought to profit by pirating the works of others and another that tried to prevent the pirates' activity. As the Internet continues to evolve, more and more of this media content is being downloaded and shared, creating another layer of complexity and another area of concern.
Similarly, content sensitive websites, such as those related to the adult industry and, until recently, the gaming industry, both gained in popularity and have become a bane to regulation because of the nature of the Internet and its lack of a single jurisdiction and enforceable standards. Efforts have been launched—expensive and complex efforts—to impose self-regulation and prosecution; however, protecting minors and regulating commerce over what is arguably an international jurisdiction has proven difficult at best. The compound problem is how to regulate a structure that does not have a conventional “place of business” without violating the rights of the individuals and of the groups who, depending upon the jurisdictions in which they reside, may have varying degrees of privacy rights and legal protections that must be balanced against any effort to regulate virtual-jurisdiction and commerce over the Internet. Virtual commerce over a virtual environment creates a need to establish agreements as to rights and jurisdiction for the protection and prosecution of those rights. However, the nature of eCommerce creates an additional need to identify the consumer, while protecting that consumer's identity from “identity theft” and “identity fraud,” and while protecting the transaction for both the consumer and the merchant.
Currently, the vendor bares much of the risk in an Internet transaction. If a minor has “borrowed” a parent's credit card, debit card, or prepaid card, if someone has stolen another person's identity, if someone has misrepresented their age as a ploy to enter a restricted site; then, the vendor's claim for payment may be denied. All of these things represent a real problem for the eCommerce merchant who seeks compensation for what they offer because that merchant assumes the risk for a transaction, not the issuing bank, where there is no signed receipt—“no signature present.” The result from this is millions of dollars of fraud, repudiation, and chargebacks of transactions, which raise the costs and risks for all.
In view of the foregoing, this disclosure presents a method, system, and structure that creates, records, verifies, and makes a storable version of a consumer's encrypted individual agreement identifiers that can be, among other things, embedded with media purchased or otherwise acquired over a computer network and onto the transactional authorization, receipt and/or record of sale, creating a “person present”/“signature present” verifier.
The method includes the use of any or all user encrypted agreement identifiers, which are created before or during storage to the user's hard drive or otherwise similar purpose computer storage system. The method and system includes allowing encrypted agreement identifiers to be used without revealing certain of the encrypted information, such as name, address, or credit/debit/prepaid card numbers, to the vendor with whom a transaction, for instance the purchase of media, is being conducted. In other words, the need to consistently register and expose a consumer's identity and information with vendors and their databases is eliminated with embodiments herein.
The method and system allows the encrypted agreement identifiers to be used as a means of verifying user acceptance of qualified terms of use and purchase, in a way that can also be embedded in downloadable media. The method and system creates and controls sub-accounts with unique user reporting and corresponding password identifiers. The method and system places the control responsibility for an account and any sub-accounts with the primary authorized/registered user. The encrypted identifiers enable a method and system for securing and limiting the access and use of the media acquired to the use, terms, and privilege for which it was acquired, thus allowing for the agreed enforcement of copyrights and other protections.
More specifically, this disclosure presents a system and method of facilitating computerized purchase transactions of electronically storable items (which are sometimes referred to herein as electronic items) such as literary works, musical works (recordings), and video works (movies, shows, videos, etc.) wherein the consumer agrees to enforcement of adhering rights, such as copyrights.
The embodiments herein encrypt “customer information” in an encryption stream (which is sometimes referred to as a customer identifier (CID) code). Such customer identifier information may comprise a name identifier (which may or may not be the customer's formal name), a possible customer age identifier (which can be a birthdate, a specific age, an age range, an age classification), a possible address identifier (which can be a customer's address or a different address), and a customer agreement identifier that contains or identifies the contractual agreement between the customer and a verification entity or financial institution (credit issuer) that will facilitate the purchase transaction.
It is possible that once the elements of an encryption stream are identified and agreed upon, a single, unique identifier may be employed by the verification entity to locate and identify that specific stream of customer information (including a computer identifier). The customer information is stored only in the verification database and only the identifier and the at-point-of-sale computer identifier can be transmitted as the encryption stream (together with non-encrypted BIN or credit issuer routing number) to the vendor.
One intent of the program and the participants is to create a “signature present verified transaction” that may be relied upon by all parties to the transaction while allowing identity protection for the customer.
The embodiments herein cause the encryption stream to be transferred from the customer to a merchant in the purchase transaction for the purchased electronic item. The verification entity, which may be the credit issuer or the credit issuer's processor or agent (e.g., the verification entity), receives the encryption stream which (in combination with the purchase price) is sent by the merchant for identity verification and payment authorization prior to payment processing. Then, the verification entity cross-references the encryption stream against a separate database containing the customer information to produce the identity verification and payment authorization. Then, the verification entity transfers the identity verification and payment authorization to the merchant, who completes the transaction with the customer and processes the transaction for payment as a “signature present” verified transaction by pre-agreement of all parties.
The identity verification and payment authorization confirms to the merchant the actual presence of the customer in the purchase transaction, such that the merchant is provided assurance that the merchant is not transacting with any entity other than the customer and that the customer has agreed to be bound by the terms of a transaction verified under the customer-credit issuer agreement. The customer-credit issuer agreement anticipates the use of and reliance upon that agreement in third party transactions, in part, in exchange for identity protection and the convenience of the embodiments herein.
With embodiments herein, the encryption stream contains identifiers—not necessarily the personal customer information—that have been agreed upon by and between the customer and the credit issuer (e.g., bank), and the identity verification and payment authorization contains information limited to a unique transaction, as anticipated and agreed upon by and between the customer and the credit issuer. Such identifiers would be of little use even if the encryption stream is decrypted.
Another feature of embodiments herein is that the encryption stream, or transaction verification, may be added, by the merchant, to a purchased electronic item, such as downloadable digital media, to create a personalized electronic item. The encryption steam or unique transaction verification (collectively or separately sometimes referred to herein as the “transaction identifier”) can be hidden, so that the customer is unable to remove the transaction identifier from the personalized electronic item. Further, the personalized electronic item could be made non-functional (so that the personalized electronic item cannot be opened, or cannot be played, etc.) if the encryption stream or transaction identifier, in part or in whole, is ever removed. Thus, the personalized electronic item always maintains the transaction identifier and allows the customer who purchased the electronic item to be identified (through the verification entity). Additionally, the transaction identifier is added in such a way that all copies of the purchased electronic item will have the transaction identifier. Thus, because all copies of the personalized electronic item will have the transaction identifier, the customer who originally purchased the electronic item from the merchant (the source of the copies) can always be identified through reference to the verification entities secure database. The “transaction identifier” is what is returned by the verifying entity and, because it is a unique identifier, may also be usable as a media embedded identifier.
After the transaction identifier is added to the purchased electronic item to create the personalized electronic item, the personalized electronic item is supplied from the merchant to the customer. Each personalized electronic item distributed to different customers is different because of the uniqueness of each different transaction identifier, which allows the customer who originally purchased the electronic item to be identified in copies of the item. Further, the uniqueness of each transaction identifier permits the source of unauthorized copies of the purchased electronic item to be identified through the secure database maintained by the verification entity.
During customer registration (when the customer is setting-up or modifying their account with the credit issuer) and during the purchase of electronic items, the customer can be provided with a notice or warning that their information will always remain with copies of any personalized electronic items. In addition, during the purchase of an electronic item, a similar notice or warning can be displayed informing the customer that he/she is agreeing to be bound by the terms and penalties provided for unauthorized use or copying of the electronic item; and, each time (or the first few times) the personalized electronic item is opened, played, etc. the same warning may be displayed. Such continuous warnings may or may not be applicable to certain downloadable media such as music. Such warnings are intended to discourage the customer from supplying copies of the personalized electronic item to others in violation of the rights of the merchant (e.g., illegally uploading or copying) because the customer is made aware, through the warnings, that the illegal uploading or copying can be traced back to them through the verification entity using the transaction identifier and/or encryption stream and is agreeing to be bound by the conditions and terms set forth in those warnings. Similar authorized use and acceptance warnings may also be employed for access based upon age, sale pricing based upon age or residence, etc. The embodiments herein allow for a wide range of customer identifiers that encourage, promote, and protect eCommerce and the parties engaging in it.
The copyright warnings, etc., may not be applicable to audio media after it is downloaded. These warnings are important prior to any downloading, however, to the extent that the customer is agreeing to be bound by the terms and conditions contained in such warnings as a condition of the transaction, he/she is agreeing to be bound under the adhesion provisions of his/her agreement with the credit issuer and is agreeing to be liable for breach of terms and conditions. The parties are agreeing to be responsible for their actions and intensions.
The encrypting of the customer information can be, for example, performed as follows. First, the customer connects with the credit issuer using a first computerized device and the credit issuer downloads software to the first computerized device. Vendors (which are interchangeably sometimes referred to herein as “merchants”) may also act as a registering agent for a credit issuer by redirecting a customer to the credit issuer's site for registration with the verification entity. The advantage to this, for example, is that once an existing credit card user registers his/her card under the program, that user/customer may elect to restrict the use of the “card” on a computer network such as the Internet to embodiments herein, protecting the “card” from unauthorized use by others. The customer supplies or agrees to allow storage of existing sensitive information, such as valid shipping addresses, their date of birth (for age group classification), their bank account numbers, credit card numbers, etc. Certain items of the customer information (such as bank account numbers and credit card numbers) are not stored on the customer's computerized device, but instead are only maintained in the databases of the credit issuer or the verification entity, though coded or un-coded identifiers may be used to specifically reference such information. Other items or identifiers (name, address, age reference, etc.) of the customer information may be encrypted to create the encryption stream, which is stored on the customer's computerized device and which may be coded or un-coded prior to encryption, in part or in whole.
The term “credit issuer” herein is a shorthand term for the entity that extends credit to the customer. This can be a merchant, vendor, bank, financial institution, etc. Further, any such credit issuers can include a verification entity and can act through an agent. Therefore, the term “credit issuer” is used to represent any and all of the foregoing. The credit issuer, as discussed in this document, may be one of several types. One type is a credit card, debit card, or similar type of issuer. Another type of issuer could be an entity that allows existing credit vehicle holders, such as existing credit card holders, to register all of the “cards” they wish to use with a single entity which would then act as the processor. Another type could be a non-card/non-bank type of credit issuer, such as a Microsoft® or a Yahoo!® or a Google®, that determines a line-of-credit for an individual, on a case by case basis, and extends to them an identifiable credit amount that may be used by the individual over a network such as the Internet. One ordinarily skilled in the art would understand that there are many other types of credit issuers that are not listed here, but that could be components of embodiments herein.
Credits are processed by the credit issuer or its processor, sometimes acting as the verifier, with participating vendors that do business over the network (this alternative recognizes that conventional credit cards may not be necessary on a computer type of network and that what is necessary is the need to protect the parties to the transaction while tracking the flow of legitimate commerce). The vendors may choose to promote this program by referring customers to their credit issuer for enrollment. This protects the customer and his/her identity, improves the marketability of the vendor, assures the vendor of payment, and reduces chargebacks and fraud; all serving to improve the vendor's bottom-line.
Banks and software companies are capable of reading and verifying a computer's identity without downloading software onto a “visitor's” computer; however, software can be downloaded or otherwise installed in order to perform the other tasks. With the customer's authorization, the credit issuer reads and registers the unique hardware identifiers (such as serial numbers from the motherboard, the hard drives, the processor, etc.) from the first computerized device. These unique hardware identifiers are also incorporated into the encryption stream. Then, the same steps are repeated for any additional computerized devices the customer desires to authorize and register for use in future purchase transactions, if, for example, the customer owns or has access to multiple computers and computerized devices. Such processes can be done when the customer is setting up or modifying their account with the credit issuer.
The verification entity, financial institution, and/or credit issuer, (e.g., a bank), sets up the elements of the encryption stream with the customer, including the initial contract/agreement that will be relied upon by any vendor supporting this program. It is the agreement between the credit issuer and the customer that is relied upon by the vendor under the terms of its merchant bank/acquirer agreement. Also, the verifying entity may be the credit issuer, or it may be a processor or agent used by the credit issuer, which processor or agent has access to the database containing the customer's information.
Some examples of customer types include: 1) new customer (applying for computer network credit; a new credit card; a new debit card or other form of “loaded” card such as a payroll debit card); 2) existing relationship (holder of an existing credit vehicle, such as the types in number 1, above, that may be used for purchases over a computer network such as the interne* or 3) new customer with existing credit vehicle (a person with existing credit vehicles/cards, such as the type described in number 1, above, may chose to register some or all of those “cards” with a single entity that would allow the “program” to be attached to all of the registered “cards”).
The “credit” may be in the form of an existing credit card, debit card, etc., or it may take the form of a newly issued “credit” from some other source willing to extend such credit to an identifiable individual—a sort of electronic-letter-of-credit, or eCredit—subject to various rules and regulations. It is during the process of registering the customer's identifiers and other information with this credit issuer—a bank will presumably have an existing customer's information in its database—that the customer and the credit issuer form the agreement of what identifiers are to be present, along with the hardware information of the registered device(s), to confirm the customer's presence.
Elements of the customer information such as age identification can be extrapolated from the database, rather than being stored in the encryption stream, although a date-of-birth or a unique word may be part of the encryption stream.
In another embodiment, as one process of further verifying that the merchant is dealing with no one else other than the customer, at the approximate time of transfer of the encryption stream to the merchant, but before the actual transfer of the encryption stream to the merchant (as part of the process of transferring the encryption stream) the method can incorporate, into the encryption stream, a second set of computer hardware identifiers and a time and date stamp from the computerized device making the actual transfer of the encryption stream. Thus, if an unscrupulous person were able to obtain an improper copy of the encryption stream, and was using the improper copy of the encryption stream on a computer (other than one of the customer's computers that are registered with the verification entity) possibly together with the necessary credit issuer supplied encryption stream creation and transfer software, the second hardware identifiers that are read just prior to the transfer of the encryption stream would not match the hardware identifiers in the encryption stream and the transaction would not be approved by the verification entity. Similarly, the time and date stamp could be used to make the encryption stream that is supplied to the merchant only valid for a limited time period (e.g., minutes, hours, days, etc.). Such processes further enhance the “customer presence” verification process performed by the verification entity to provide additional assurances to the vendor that they are actually dealing with the customer and not someone other than the actual customer. In addition to verifying the customer's presence and agreement to terms whenever the customer uses the encryption steam/signature, the embodiments herein permit the credit issuer to disallow a specific vendor into the program, where vendor fraud is, or has been, an issue. This further serves to protect the customer, as well as reputable vendors.
The use of a standard credit issuer software program for creation of the encryption stream on the customer's computerized device and the transfer the encryption stream to the merchant for the verification step ensures that the device upon which the software resides will be identified. Thus, if that identifier does not match the identifier in a hypothecated encryption stream, the transaction will not be approved.
Embodiments herein also comprise one or more systems that use an encoder that is positioned within the customer's computer by the credit issuer. The encoder encrypts the customer identifier information in the encryption stream. In addition, the credit issuer positions a transfer agent within the customer's computer and with the merchant. The transfer agent causes the encryption stream to be transferred from the customer's computer to the merchant's computer in the purchase transaction for the purchased electronic item.
The verification entity has a verifier that is operatively connected to both the customer's computer and/or the merchant's computer during the verification stage of a transaction. In embodiments herein, in order to enhance the security of the customer information, the verifier is maintained separate from the customer's computer and from the merchant by being maintained in the verification entity. A database of the customer payment information can be maintained within the verification entity or separate from the verification entity. In either situation, the database is operatively connected only to the verifier, and neither the customer nor the merchant have access to the database.
To perform the method steps herein, the transfer agent is adapted to cause the encryption stream to be transferred from the merchant's computer to the verifier for payment verification. The verifier is further adapted to generate the identity verification and payment authorization, based on the database information, and to transfer the identity verification and payment authorization to the merchant. Again, the encryption stream or the unique identity verification and payment authorization is adapted to be added, by the merchant, to the purchased electronic item to create the personalized electronic item that is supplied from the merchant to the customer.
III. Background and Summary of Continuation-In-Part Disclosure Claiming Priority to U.S. Provisional Application 61/039,532 Priority Date: Mar. 25, 2008
Issues also arise when there is a need to reduce the amount of information stored on a customer's electronic device and when there is a need to have an attestation from the customer that they are present. Unlike the traditional “in person” shopping experience using a credit or debit card, there is no signed sales receipt on the Internet. There is no sure way for a merchant, for instance, to dispute a cardholder claim. The cardholder may say they did not make the purchase, and because there is no signature, the merchant is responsible for charges. Customers are at risk of losing their identity, and merchants are at risk for chargebacks and other sale related loses.
The embodiments of the present invention allow a customer to engage in a transaction without revealing that customer's personal or financial information to a vendor or a third-party (collectively hereinafter “vendor”) where both the customer and the vendor have each entered into a prior cardholder or merchant agreement, under which they have separately agreed to be bound by the terms and obligations any transaction where the issuing bank or entity (hereinafter “issuing bank”) confirms that all elements required under the invention are present and that the obligations due the merchant are or shall be met.
One method of securing such transactions over a computer network to achieve these goals is divided into two stages. The first stage occurs when a customer is setting up an account (possibly through a third party, such as a portal website or the issuing bank's processor, such as is common with debit cards, that has contracted with an issuing bank) and the second stage occurs when the customer is actually completing secure transactions through their electronic device. An additional part of the first stage can also be the process of a merchant contracting with an acquiring bank. An issuing bank is a bank that offers card association branded payment cards directly to consumers, and an acquiring bank (or acquirer) is the bank or financial institution that accepts payments for the products or services on behalf of a merchant. The term acquirer indicates that the bank accepts or acquires transactions performed using a credit card issued by a bank that may be a bank other than itself.
When establishing the account, the method establishes an agreement between the customer and the issuing bank. Similarly, the merchant enters an agreement with the acquiring bank. As described above, the customer agreement can bind the customer to many obligations including attesting that they will be responsible for any transactions, and the terms of such transactions, properly consummated through their electronic device, and approved by the issuing bank under the terms of the cardholder agreement, irrespective of whether the customer claims, later, not to have approved of such transactions. Further, as mentioned above, the agreement can allow a merchant to add a unique transaction identifier to any downloadable electronic items that the customer may purchase (where the unique transaction identifier can be used by the issuing bank to later identify the customer as being the source of any illegal copies of the downloadable electronic items).
Also, when establishing the account, the method downloads computer readable instructions from the issuing bank or acquiring bank over the computer network to an electronic device (computer, PDA, cell phone, etc.) associated with the customer or the merchant. Using the instructions, the method stores at least one permitted password, at least one customer identifier string, and permitted hardware identifiers in at least one folder on storage media of the customer's electronic device. The customer identifier string may not contain any personal customer information, but instead can be an alphabetic, numeric, or alpha-numeric string of characters that the financial institution uses to identify the customer.
There can be multiple folders created on the storage media of the customer's electronic device. Thus, the method can use the instructions to store different passwords in different folders, store different customer shipping addresses in different folders, store different payment methods in different folders, and/or store different purchase restrictions in different folders, etc.; or, the instructions can allow a single password, or PIN, to access all stored folders for the appropriate selection by the customer at the time of a specific transaction.
Further, the instructions are used to transmit the customer identifier string, the permitted hardware identifiers, etc., to a financial institution or verification entity that is separate from the third party.
When transacting a purchase, the method operates by receiving an input password from the customer who is operating the electronic device. The method determines if the input password matches the permitted password (to determine if the input password is valid). The determination of the validity of the password is performed locally by the instructions stored on the customer's electronic device.
If the permitted password is valid, the method reads current hardware identifiers from hardware of the electronic device. As discussed in greater detail above, the current hardware identifiers can comprise at least a portion of a serial number of at least one hardware component of the customer's electronic device. The method compares the current hardware identifiers with the permitted hardware identifiers to determine if the current hardware identifiers are valid. Again, this determination of the validity of the hardware identifiers is performed locally by the instructions stored on the customer's electronic device.
If the current hardware identifiers match the permitted hardware identifiers, the instructions on the customer's electronic device cause the electronic device to retrieve the customer identifier string from the storage media of the electronic device. Further, during this processing, the instructions cause the incrementing of a sequencer maintained by the electronic device to update a unique count.
Then, the method encrypts the customer identifier string, the current hardware identifiers, and the unique count as an encrypted customer code at the customer's electronic device. Any form of encryption can be used (for example, one, two, three, etc. public keys could be used that operate with the financial institution's private key). If desired, as another layer of security, a time and date stamp can be added to the encrypted customer code. After so encrypting the customer code, the method can add non-encrypted routing information to the customer code to allow the customer code to be routed to the proper financial institution.
The sequencer is incremented before each purchase transaction so that each separate customer code associated with each purchase transaction has a different unique count. The sequencer operating within the customer's electronic device and a separate sequencer maintained by the financial institution are synchronized with the completion of each transaction so that the financial institution can verify each new unique count produced by the sequencer within the customer's electronic device. By using a different unique count in each encrypted customer code for each purchase transaction, yet another layer of security is provided to the customer. In other words, if any given encrypted customer code were stolen and resubmitted to the financial institution in a subsequent transaction, the unique count encrypted into the customer code would be valid only for the original purchase transaction, and the financial institution would be alerted to a fraudulent transaction if any count other than the currently expected unique count were presented in a subsequent purchase.
Next, this encrypted customer code is supplied (transmitted) to the participating merchant through which the customer desires to complete the transaction. Only a participating merchant, who has executed a merchant's agreement providing for the embodiments of the present invention, and who has downloaded and installed the appropriate API (application programming interface) on its server, is capable of receiving and transmitting the encrypted customer code to the issuing bank for verification and completion of the transaction. As mentioned above, the merchant executes the merchant agreement with an acquiring bank or financial institution and downloads the API, both possibly through the third party. Once the API has been activated on the merchant's server, the merchant is prepared to receive the encrypted customer code.
This encrypted customer code does not include any personal or financial information of the customer (e.g., does not include the customer's name or customer credit card numbers or customer bank account numbers) but, instead, the customer code includes the hardware identifiers, the unique count, and the customer identifier string (which is simply a code used by the financial institution to identify the customer). Therefore, the private financial information is never provided to the merchant (either in encrypted or unencrypted form).
The merchant then forwards the encrypted customer code from the merchant to the issuing bank over the designated computer network. The issuing bank decrypts the encrypted customer code. If the customer identifier string, the current hardware identifiers, and the unique count match records maintained by the financial institution (and all other necessary requirements are met, e.g., the customer has sufficient money in their account or sufficient credit remaining); the financial institution transmits a purchase authorization, or confirmation authorization, from the financial institution to the merchant over the computer network. Also, an electronic message can be sent from the issuing bank to the customer informing the customer that a transaction authorization has been provided to the merchant. This permits the customer to object to the issuance of any transaction authorizations that were not expected, and which may be fraudulent.
The transaction authorization and the customer's agreement to be bound by the terms of all such transactions create an attestation from the customer to the merchant that the customer is physically present for person present processing. Then the merchant, under prior agreement and personal contract verified by the issuing bank, completes the transaction and, in the case of a purchase transaction, ships or transmits the item being purchased to the customer.
In one optional embodiment, the issuing bank can supply the customer's valid shipping address, provided the customer has selected a stored folder that instructs the issuing bank to provide specific, approved shipping information, along with the purchase authorization so that the customer can save time when completing the purchase screen on the merchant's web site.
In addition, if the item being purchased is a downloadable electronic item (such as those mentioned above) the merchant can be supplied with a unique transaction identifier along with the payment authorization. Thus, the method could transmit the unique transaction identifier and the purchase authorization from the financial institution to the merchant over the computer network. This would allow the merchant to add the unique transaction identifier to the downloadable electronic item to produce a unique downloadable electronic item that is transmitted to the customer. As described above, the unique transaction identifier allows the financial institution to identify the customer who purchased the downloadable electronic item from the merchant, thereby identifying the individual who may be the source of subsequently discovered illegal copies and providing a disincentive for customers to make illegal copies of downloadable electronic items, such as music files, videos, books, etc.
Further, if the customer's agreement with the issuing bank includes an agreement to be bound by non-infringement of copyright protections, the owners of the copyrighted content would be afforded additional protections under the cardholder and merchant agreements.
These and other aspects of the embodiments of the invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments of the invention and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments of the invention without departing from the spirit thereof, and the embodiments of the invention include all such modifications.